Files that changed from the base of the PR and between 4bb0967 and 8bb9c6c.

• Cargo.lock is excluded by !**/*.lock

• .github/workflows/main.yml (1 hunks)
• .github/workflows/pr-checks.yml (1 hunks)
• Cargo.toml (1 hunks)
• README.md (1 hunks)
• deny.toml (1 hunks)
• examples/async_api.rs (1 hunks)
• src/client/asynchronous.rs (1 hunks)
• src/client/blocking.rs (9 hunks)
• src/client/builder.rs (3 hunks)
• src/client/mod.rs (3 hunks)
• src/connection/asynchronous.rs (1 hunks)
• src/connection/blocking.rs (3 hunks)
• src/connection/mod.rs (1 hunks)
• src/graph/asynchronous.rs (1 hunks)
• src/graph/blocking.rs (20 hunks)
• src/graph/mod.rs (1 hunks)
• src/graph/query_builder.rs (11 hunks)
• src/graph_schema/mod.rs (9 hunks)
• src/lib.rs (3 hunks)
• src/parser/mod.rs (16 hunks)
• src/response/constraint.rs (2 hunks)
• src/response/index.rs (4 hunks)
• src/response/lazy_result_set.rs (2 hunks)
• src/response/mod.rs (1 hunks)
• src/value/graph_entities.rs (1 hunks)

• deny.toml

src/connection/mod.rs (2)

10-11: LGTM! The conditional compilation flag #[cfg(feature = "tokio")] is correctly used to include the asynchronous module only when the tokio feature is enabled.

---

13-21: The error mapping function map_redis_err is well-implemented, providing a clear mapping from Redis errors to internal FalkorDBError types. This ensures that the error handling is consistent and understandable.

Cargo.toml (3)

16-16: The addition of tokio with specific features such as macros, sync, and rt-multi-thread is appropriate for enabling asynchronous programming capabilities in the project. Ensure that these features align with the project's async requirements.

---

16-16: Including tracing as an optional dependency with features like std and attributes is a good choice for enhanced logging and debugging capabilities, especially in asynchronous environments.

---

20-27: The configuration of feature flags, particularly the new tokio feature set and its dependencies, is well-organized. This setup facilitates easy toggling of asynchronous support and its associated dependencies.

.github/workflows/pr-checks.yml (1)

55-55: Adding test-threads 8 to the cargo nextest run --all command is a practical approach to increase test parallelism. This should help in reducing the overall test execution time, provided that the CI environment has sufficient resources to handle multiple threads effectively.

.github/workflows/main.yml (1)

44-44: The inclusion of --test-threads 8 in the cargo llvm-cov nextest command is a good enhancement for speeding up the code coverage generation process. Similar to the test job, ensure that the CI environment can efficiently manage the specified number of threads.

src/graph/mod.rs (2)

15-17: The HasGraphSchema trait is well-defined. Ensure that it is adequately implemented in all relevant graph structures to maintain the integrity of the schema modifications.

---

6-7: Ensure that all the necessary traits and types from these imports are being utilized in the module to avoid unused imports.

Also applies to: 12-13

Verification successful

---

All imported traits and types are being utilized in the src/graph/mod.rs file.

• EntityType is used.
• GraphSchema is used.
• IndexType is used.
• HashMap is used.
• Display is used.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify that the imported traits and types are utilized in `src/graph/mod.rs`.

# Search for unused imports in the file.
ast-grep --lang rust --pattern $'use $_ { $$$ };' src/graph/mod.rs

Length of output: 67

---

---

Script:

#!/bin/bash
# Description: Verify that the imported traits and types are utilized in `src/graph/mod.rs`.

# Check for the usage of EntityType
rg -q 'EntityType' src/graph/mod.rs && echo "EntityType used" || echo "EntityType not used"

# Check for the usage of GraphSchema
rg -q 'GraphSchema' src/graph/mod.rs && echo "GraphSchema used" || echo "GraphSchema not used"

# Check for the usage of IndexType
rg -q 'IndexType' src/graph/mod.rs && echo "IndexType used" || echo "IndexType not used"

# Check for the usage of HashMap
rg -q 'HashMap' src/graph/mod.rs && echo "HashMap used" || echo "HashMap not used"

# Check for the usage of Display
rg -q 'Display' src/graph/mod.rs && echo "Display used" || echo "Display not used"

Length of output: 366

src/response/constraint.rs (1)

53-68: The implementation of SchemaParsable for Constraint is robust. However, ensure that the tracing attributes are correctly configured if the tracing feature is used elsewhere in the project.

Verification successful

---

The inspection of the identified files confirms that the tracing attribute is consistently used across the project where the tracing feature is enabled. The implementation of SchemaParsable for Constraint appears robust and the tracing attributes are correctly configured.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the usage of `tracing` feature across the project.

# Search for the `tracing` feature usage in Rust files.
rg --type rust 'feature = "tracing"' --files-with-matches

Length of output: 529

---

---

Script:

#!/bin/bash
# Description: Inspect the usage of the `tracing` attribute in the identified files.

# Define the list of files to inspect
files=(
  "src/value/graph_entities.rs"
  "src/value/point.rs"
  "src/value/path.rs"
  "src/response/mod.rs"
  "src/response/lazy_result_set.rs"
  "src/response/index.rs"
  "src/response/constraint.rs"
  "src/response/slowlog_entry.rs"
  "src/response/execution_plan.rs"
  "src/parser/mod.rs"
  "src/graph_schema/mod.rs"
  "src/graph/query_builder.rs"
  "src/graph/blocking.rs"
  "src/graph/asynchronous.rs"
  "src/connection/blocking.rs"
  "src/client/mod.rs"
  "src/client/blocking.rs"
  "src/client/asynchronous.rs"
  "src/connection/asynchronous.rs"
)

# Loop through the files and search for the `tracing` attribute usage
for file in "${files[@]}"; do
  echo "Inspecting $file"
  rg '#\[cfg_attr(feature = "tracing"' "$file"
done

Length of output: 5575

---

---

Script:

#!/bin/bash
# Description: Inspect the usage of the `tracing` attribute in the identified files.

# Define the list of files to inspect
files=(
  "src/value/graph_entities.rs"
  "src/value/point.rs"
  "src/value/path.rs"
  "src/response/mod.rs"
  "src/response/lazy_result_set.rs"
  "src/response/index.rs"
  "src/response/constraint.rs"
  "src/response/slowlog_entry.rs"
  "src/response/execution_plan.rs"
  "src/parser/mod.rs"
  "src/graph_schema/mod.rs"
  "src/graph/query_builder.rs"
  "src/graph/blocking.rs"
  "src/graph/asynchronous.rs"
  "src/connection/blocking.rs"
  "src/client/mod.rs"
  "src/client/blocking.rs"
  "src/client/asynchronous.rs"
  "src/connection/asynchronous.rs"
)

# Loop through the files and search for the `tracing` attribute usage with corrected regex pattern
for file in "${files[@]}"; do
  echo "Inspecting $file"
  rg '#\[cfg_attr\(feature = "tracing"' "$file"
done

Length of output: 3808

src/lib.rs (1)

68-99: The asynchronous test utilities are well-structured. Ensure that the async test clients and graph handles are used consistently across all tests to maintain uniformity in test execution.

Verification successful

---

The TestAsyncGraphHandle is consistently used across the codebase, particularly within test-related contexts, ensuring uniformity in test execution.

• src/lib.rs: Struct definition, Drop trait implementation, and an async function returning TestAsyncGraphHandle.
• src/client/asynchronous.rs: Import and variable assignment within test-related context.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the usage of asynchronous test utilities across tests.

# Search for usage of `TestAsyncGraphHandle` in test files.
rg --type rust 'TestAsyncGraphHandle' --files-with-matches

Length of output: 96

---

---

Script:

#!/bin/bash
# Description: Extract usage of `TestAsyncGraphHandle` in `src/lib.rs` and `src/client/asynchronous.rs`.

# Extract lines containing `TestAsyncGraphHandle` in `src/lib.rs`.
echo "Usage in src/lib.rs:"
rg 'TestAsyncGraphHandle' src/lib.rs

# Extract lines containing `TestAsyncGraphHandle` in `src/client/asynchronous.rs`.
echo "Usage in src/client/asynchronous.rs:"
rg 'TestAsyncGraphHandle' src/client/asynchronous.rs

Length of output: 553

src/value/graph_entities.rs (1)

95-96: The parsing logic for Edge correctly integrates the parse_single_id method for relationship type IDs. Ensure that the parse_single_id method is robust and handles all edge cases, especially for different types of relationships.

examples/async_api.rs (3)

6-8: Imports and async setup look correct and are well-organized.

---

33-37: Using Arc and Mutex for graph objects is a good practice in this context, ensuring thread safety across async tasks.

---

38-62: The use of JoinSet for managing multiple async tasks is a good demonstration of tokio's capabilities. However, ensure that the results are handled correctly, especially since the order of results is not guaranteed.

Verification successful

To ensure comprehensive verification, let's check if there is a higher-level error handling mechanism in place for the async tasks in the JoinSet.

---

The provided output confirms that the results are correctly unwrapped and processed, and the order of results is documented as non-guaranteed. Additionally, the use of res? ensures that any errors are propagated. There is no higher-level error handling mechanism beyond this, but the current implementation seems appropriate for the given context.

• The results are correctly unwrapped using res?.
• The order of results is explicitly documented as non-guaranteed.
• Errors are propagated using res?, which is a common idiomatic approach in Rust.

No further issues are found with the handling of async tasks in the JoinSet.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that the async tasks in the join set handle results correctly
ast-grep --lang rust --pattern $'while let Some(Ok(res)) = join_set.join_next().await {
  $$$
}'

Length of output: 341

---

---

Script:

#!/bin/bash
# Check for higher-level error handling mechanism in examples/async_api.rs
rg --context 5 'let actual_res = res?' examples/async_api.rs

Length of output: 584

src/connection/blocking.rs (3)

7-10: Updated imports and internal usage reflect the changes in the API and dependency structure correctly.

---

46-46: Ensuring that Redis commands are executed properly and errors are mapped correctly is crucial for database operations. This change appears to handle that well.

---

61-62: The integration of the parse_redis_info function in the connection info retrieval process is a good enhancement for handling Redis server responses.

src/response/index.rs (3)

8-10: Updated parsing utilities and imports are well-organized and reflect the new functionalities introduced in the API.

---

40-69: The refactored parse_types_map function is a significant improvement, making the parsing logic more robust and maintainable. Ensure that all possible error cases are handled correctly.

Verification successful

To verify that all possible error cases in the parse_types_map function are handled correctly, we need to examine the function's implementation in detail. We should look for all the points where errors could occur and ensure that each of these points has appropriate error handling.

---

Let's correct the argument and rerun the script to gather the necessary information.

---

Let's use rg to locate the parse_types_map function and extract its implementation for a thorough review of the error handling.

---

To get the complete implementation of the parse_types_map function for thorough analysis, we need to extend the search.

---

The parse_types_map function appears to handle various error cases appropriately by returning specific FalkorDBError variants when certain conditions are not met or when operations fail. The function checks for type markers, handles errors during map iteration, and ensures the correct type for array elements.

• The function returns FalkorDBError::ParsingMap if the type marker is not 10.
• It handles errors during the conversion to a map iterator with FalkorDBError::ParsingMap.
• It checks for the correct type marker for arrays and returns FalkorDBError::ParsingArray if the marker is incorrect.
• It ensures that the values can be converted to a vector and handles errors accordingly.

The error handling in the parse_types_map function seems robust and covers various potential failure points.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that all error cases in parse_types_map are handled correctly
ast-grep --lang rust --pattern $'fn parse_types_map($_) {
  $$$
}'

Length of output: 67

---

---

Script:

#!/bin/bash
# Locate the parse_types_map function implementation in the codebase
ast-grep --lang rust --pattern 'fn parse_types_map($_) {
  $$$
}'

# Extract the parse_types_map function code to analyze error handling
ast-grep --lang rust --pattern 'fn parse_types_map($_) {
  $$$
}' --debug

Length of output: 350

---

---

Script:

#!/bin/bash
# Locate the parse_types_map function implementation in the codebase
ast-grep --lang rust --pattern 'fn parse_types_map($_) {
  $$$
}'

# Extract the parse_types_map function code to analyze error handling
ast-grep --lang rust --pattern 'fn parse_types_map($_) {
  $$$
}' --debug-query

Length of output: 231

---

---

Script:

#!/bin/bash
# Locate the parse_types_map function implementation in the codebase
rg 'fn parse_types_map' -A 20

Length of output: 1308

---

---

Script:

#!/bin/bash
# Locate the complete implementation of the parse_types_map function in the codebase
rg 'fn parse_types_map' -A 50

Length of output: 3073

---

Line range hint 93-119: The implementation of SchemaParsable for FalkorIndex is well done, encapsulating the parsing logic effectively. However, ensure that the parse_raw_redis_value function is robust against all input variants.

Verification successful

---

The parse_raw_redis_value function calls type_val_from_value and parse_type to handle different input variants. The type_val_from_value function ensures the input is a vector with exactly two elements and parses them into an integer type marker and a Redis value. The parse_type function handles various type markers, converting the input value into different FalkorValue variants, and includes robust error handling for unexpected types.

• parse_raw_redis_value is robust against various input variants due to the combined validation and parsing logic in type_val_from_value and parse_type.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify robustness of `parse_raw_redis_value` against all input variants
ast-grep --lang rust --pattern $'fn parse_raw_redis_value($_, $_) {
  $$$
}'

Length of output: 77

---

---

Script:

#!/bin/bash
# Search for the `parse_raw_redis_value` function definition in the codebase
rg 'fn parse_raw_redis_value'

Length of output: 86

---

---

Script:

#!/bin/bash
# Extract the implementation of the `parse_raw_redis_value` function from `src/parser/mod.rs`
ast-grep --lang rust --pattern $'fn parse_raw_redis_value($_, $_) {
  $$$
}' --json

Length of output: 87

---

---

Script:

#!/bin/bash
# Locate the exact line of `parse_raw_redis_value` definition and extract the surrounding lines for manual inspection
rg --line-number 'fn parse_raw_redis_value' src/parser/mod.rs
# Extract lines around the located function definition
awk 'NR>=start_line-5 && NR<=end_line+5' start_line=$(rg --line-number 'fn parse_raw_redis_value' src/parser/mod.rs | cut -d: -f1) end_line=$(($(rg --line-number 'fn parse_raw_redis_value' src/parser/mod.rs | cut -d: -f1) + 20)) src/parser/mod.rs

Length of output: 1419

---

---

Script:

#!/bin/bash
# Extract the implementation of the `type_val_from_value` function from `src/parser/mod.rs`
ast-grep --lang rust --pattern $'fn type_val_from_value($_) {
  $$$
}' --json

Length of output: 81

---

---

Script:

#!/bin/bash
# Extract a larger portion of the file around the `type_val_from_value` function for manual inspection
awk 'NR>=start_line-10 && NR<=end_line+20' start_line=$(rg --line-number 'fn type_val_from_value' src/parser/mod.rs | cut -d: -f1) end_line=$(($(rg --line-number 'fn type_val_from_value' src/parser/mod.rs | cut -d: -f1) + 20)) src/parser/mod.rs

Length of output: 1864

---

---

Script:

#!/bin/bash
# Extract the implementation of the `parse_type` function from `src/parser/mod.rs`
ast-grep --lang rust --pattern $'fn parse_type($_, $_, $_) {
  $$$
}' --json

Length of output: 80

---

---

Script:

#!/bin/bash
# Locate the exact line of `parse_type` definition and extract the surrounding lines for manual inspection
rg --line-number 'fn parse_type' src/parser/mod.rs
# Extract lines around the located function definition
awk 'NR>=start_line-10 && NR<=end_line+20' start_line=$(rg --line-number 'fn parse_type' src/parser/mod.rs | cut -d: -f1) end_line=$(($(rg --line-number 'fn parse_type' src/parser/mod.rs | cut -d: -f1) + 20)) src/parser/mod.rs

Length of output: 1964

src/connection/asynchronous.rs (1)

24-48: The execute_command method handles command execution asynchronously. It's well-structured with proper error handling. However, ensure proper testing, especially for edge cases in command parameter handling and Redis connection errors.

src/client/mod.rs (2)

154-174: The get_sentinel_client_async method is well-implemented. However, consider adding more robust error handling for the sentinel master retrieval process to handle potential inconsistencies or errors more gracefully.
[REFACTOR_Suggestion]

-            return Ok(None);
+            return Err(FalkorDBError::SentinelRetrievalFailed);

---

54-74: The get_async_connection method is implemented correctly with proper error handling. Ensure comprehensive testing, especially for the sentinel handling and multiplexed connection retrieval.

src/response/mod.rs (1)

168-172: The test modifications appear to be correct and effectively test the statistics fetching functionality.

src/client/blocking.rs (3)

7-9: The connection borrowing mechanism has been correctly updated with proper error handling and concurrency control.

Also applies to: 18-20, 51-51, 62-62

---

153-157: The modifications to configuration management methods are correctly implemented with appropriate command usage and error handling.

Also applies to: 175-182

---

241-241: The test suite modifications are well-implemented, covering critical functionalities of the blocking client.

Also applies to: 292-292

src/graph_schema/mod.rs (1)

74-74: The modifications to the schema management functionality, including refreshing and ID parsing, are well-implemented and improve the robustness of the operations.

Also applies to: 85-85, 152-152, 194-215

src/client/asynchronous.rs (1)

6-10: The implementation of the asynchronous client is correctly done with proper usage of async-await patterns and effective error handling.

Also applies to: 22-25, 33-33, 42-56, 66-68, 71-71, 80-82, 98-98, 102-127, 135-137, 147-153, 167-176, 188-202, 230-245, 252-263

src/graph/blocking.rs (5)

21-23: The SyncGraph struct correctly encapsulates the necessary components for synchronous graph operations. The use of Arc for the FalkorSyncClientInner client ensures that the client can be safely shared across threads, which is essential given that SyncGraph is not thread-safe itself. This design choice aligns well with the stated non-thread-safe nature of the struct.

---

46-48: The get_client method provides a safe way to access the FalkorSyncClientInner client. This method is crucial for maintaining encapsulation and ensuring that the client's internal state is not inadvertently modified from outside the SyncGraph class.

---

113-113: All the methods that create QueryBuilder and ProcedureQueryBuilder instances are well-implemented. They correctly pass the necessary parameters and maintain the encapsulation of the graph's state by using references to self. These methods facilitate the building and execution of various types of queries and procedures, which is central to the functionality of the SyncSraph.
[APROVED]

Also applies to: 128-128, 143-143, 159-159, 175-175, 191-191, 204-205, 233-241, 252-259, 272-273

---

384-387: The implementation of the HasGraphSchema trait for SyncGraph is essential for allowing the graph operations to access and modify the graph schema. This integration is crucial for operations that depend on the schema's current state, such as query building and execution.

---

Line range hint 393-423: The test cases are comprehensive and cover a wide range of functionalities including index creation, listing, and deletion, as well as constraint management. These tests ensure that the graph operations behave as expected and are crucial for maintaining code quality and reliability.

Also applies to: 430-465, 489-498

src/graph/query_builder.rs (11)

40-42: The QueryBuilder struct is well-designed to support building and executing queries against a graph. The use of generics for the output and graph schema types (Output, T, G) enhances the flexibility and reusability of this struct across different graph implementations.

---

49-51: The new method for QueryBuilder is implemented correctly. It initializes all fields of the QueryBuilder struct, setting up the builder pattern effectively. This method is crucial for the fluent interface provided by the builder pattern, allowing for chained method calls to configure the query further.

---

Line range hint 93-138: The generate_query_result_set method is robust, handling different possible lengths of the result set array. It uses pattern matching to destructure the results appropriately and handles errors gracefully. This method is central to transforming raw query results into structured data that can be easily used by the application.

---

149-172: The common_execute_steps method for SyncGraph is well-implemented. It constructs the query string, manages the timeout, and executes the command using the graph's client. This method is a critical part of the query execution process, encapsulating common steps to avoid code duplication.

---

175-199: The asynchronous version of the common_execute_steps method is correctly implemented with the async keyword and uses await for asynchronous operations. This method ensures that the query execution process is non-blocking, which is crucial for performance in IO-bound applications.

---

202-211: The execute methods for both synchronous and asynchronous QueryBuilder instances are correctly implemented. They finalize the query configuration and execute it, handling the results appropriately. These methods are essential for the usability of the QueryBuilder, allowing users to execute configured queries easily.

Also applies to: 214-225

---

228-241: The execution methods for QueryBuilder when the output is an ExecutionPlan are well-implemented. They use the common_execute_steps method to perform the query execution and then parse the result into an ExecutionPlan. This specialization ensures that the query builder can handle different types of queries effectively.

---

287-289: The ProcedureQueryBuilder struct and its constructor methods are correctly implemented. They allow for the creation of builders for procedure calls, which can be configured further using chained method calls. This design supports a flexible and powerful way to execute stored procedures on the graph.

Also applies to: 296-298, 313-313

---

354-377: The parse_query_result_of_type method is crucial for parsing the results of procedure calls into a specific type. It handles the parsing logic comprehensively, ensuring that the results are correctly transformed into the desired data structure. This method is essential for the functionality of the ProcedureQueryBuilder.

---

Line range hint 380-410: The common_execute_steps methods for both synchronous and asynchronous ProcedureQueryBuilder instances are well-implemented. They handle the construction and execution of the procedure call, encapsulating common logic to reduce code duplication and ensure consistency.

Also applies to: 413-443

---

447-457: The execute methods for ProcedureQueryBuilder are correctly implemented for both synchronous and asynchronous versions. They execute the procedure call and parse the results into the appropriate type. These methods are crucial for the usability of the ProcedureQueryBuilder, allowing users to execute configured procedure calls easily.

Also applies to: 460-471, 475-485, 488-498

src/parser/mod.rs (4)

48-62: The parse_redis_info function efficiently parses server information into a key-value map, handling potential errors gracefully.

---

68-101: The parse_config_hashmap function demonstrates robust error handling and clear logic for transforming Redis configuration data into a usable hashmap.

---

124-140: The redis_value_as_typed_string method uses a type marker to ensure that the Redis value is correctly interpreted as a string, enhancing type safety.

---

299-304: The SchemaParsable trait provides a clear and reusable interface for implementing parsing functionality across different data structures.

src/graph/asynchronous.rs (4)

22-26: The AsyncGraph struct is well-documented and clearly encapsulates the necessary components for asynchronous graph operations.

---

75-79: The delete method correctly handles the graph deletion and schema cache clearing in an asynchronous context.

---

209-213: The list_indices method effectively uses asynchronous patterns to retrieve and process graph indices, demonstrating clear and efficient logic.

---

327-357: The create_unique_constraint method comprehensively handles the creation of unique constraints on graph entities, utilizing both indexing and command execution in an asynchronous manner.

Files that changed from the base of the PR and between 8bb9c6c and 033226b.

• Cargo.lock is excluded by !**/*.lock

• .github/workflows/main.yml (1 hunks)
• .github/workflows/pr-checks.yml (1 hunks)
• Cargo.toml (2 hunks)
• README.md (1 hunks)
• src/client/asynchronous.rs (1 hunks)
• src/client/blocking.rs (9 hunks)
• src/client/mod.rs (3 hunks)
• src/connection/asynchronous.rs (1 hunks)
• src/connection/blocking.rs (3 hunks)
• src/error/mod.rs (1 hunks)
• src/graph/mod.rs (1 hunks)
• src/graph/query_builder.rs (11 hunks)
• src/parser/mod.rs (17 hunks)
• src/response/lazy_result_set.rs (2 hunks)
• src/value/mod.rs (2 hunks)

• .github/workflows/main.yml
• .github/workflows/pr-checks.yml
• Cargo.toml
• src/client/asynchronous.rs
• src/client/blocking.rs
• src/client/mod.rs
• src/connection/asynchronous.rs
• src/connection/blocking.rs
• src/graph/mod.rs
• src/parser/mod.rs
• src/response/lazy_result_set.rs

src/error/mod.rs (1)

115-120: The addition of errors related to single-threaded Tokio runtime and no runtime detected are crucial for robust error handling in asynchronous contexts.

src/value/mod.rs (1)

43-43: The addition of a String parameter to the Unparseable variant enhances error reporting by providing more context about the failure.

src/graph/query_builder.rs (2)

Line range hint 43-215: The refactoring of QueryBuilder to support both synchronous and asynchronous graph schemas is a significant enhancement. It allows more flexible and powerful query construction and execution strategies.

---

Line range hint 290-502: The introduction of ProcedureQueryBuilder is well-implemented, supporting both read-only and standard procedure calls. This addition enhances the modularity and reusability of procedure execution.

Files that changed from the base of the PR and between 033226b and 5531550.

• Cargo.toml (2 hunks)
• README.md (1 hunks)
• src/graph_schema/mod.rs (11 hunks)
• src/parser/mod.rs (23 hunks)
• src/response/index.rs (4 hunks)
• src/response/lazy_result_set.rs (2 hunks)

• Cargo.toml
• src/graph_schema/mod.rs
• src/parser/mod.rs
• src/response/lazy_result_set.rs

src/response/index.rs (3)

6-11: Reorganized imports and added new parsing functions enhance clarity and maintainability.

---

41-70: Refined the parse_types_map function to utilize new parsing utilities, improving clarity and error handling.

---

Line range hint 94-120: Updated the FalkorIndex parsing logic to handle different types of index data more robustly, aligning with the new parsing functions.

README.md (1)

61-94: Updated documentation to clearly explain the new tokio support, including the requirements and limitations of the async API.